@gdt - i believe the original author of the .desktop file is @mkrupcale because it's the same user name in the Fedora commit

For me any license that's acceptable to upstream is fine, i've added the MIT-0 license based on https://docs.fedoraproject.org/en-US/legal/misc/#_license_of_fedora_spec_files ... @mkrupcale please tell us if you have anything more specific in mind!

Thanks for splitting. I see the MIT-0 SPDX and given that this is near trivial in creative expression that seems adequate. Thanks also for pinging the likely author. I did a build/install to a temp DESTDIR and structurally it seems good. I wondered why in make_tools.ml it doesn't use build_GUI but I see what you added is in the same vein as the rest of that function, so that's fine.

Two nits, and I can adjust, or you:

I don't want to encode github in the desktop name. It's a bug that unison is still on github. Looking at my system (NetBSD/pkgsrc), I have 82 desktop files. Using the horrifying regexp '.*\..*\..*' to find those with a dot in the application name, there are then 25, and all of them are domain names belong to the projects, like gnome.org, kicad.org, qgis.org. There isn't a single foo.github.io. There are 58 that are just the app name, or project-app for desktoppy stuff; an example is emacs.desktop. Given that there could be a desktop-file way to start a background non-gui unison from a desktop file in the future, I'd lean to unison-gui.desktop. Syncthing has syncthing-start.desktop and synching-ui.desktop.

The comment says Multi-master File synchronization tool. That's not a phrase that i find in unison's documentation. I would lean to "GUI for Unison file synchronizer".

(I am assuming that packaging systems would be happier to have an upstream-provided desktop file, and drop their local one, seeing that as progress, even if it is a bit different.)

Flathub has a very detailed and inflexible policy about Application ID which also determines the desktop file name, so i had to follow that.

https://docs.flathub.org/docs/for-app-authors/requirements#application-id

https://docs.flatpak.org/en/latest/conventions.html#desktop-files

changing this from io.github.* effectively requires deprecating the existing application and submitting it under the new ID - certainly doable but only after you have actually established the new hosting location.

however, replacing the last part with "unison-gui" is possible:

Flatpak will export the following desktop filename patterns: $FLATPAK_ID.desktop, $FLATPAK_ID.foo.desktop, $FLATPAK_ID-foo.desktop.

@gdt - i believe the original author of the .desktop file is @mkrupcale because it's the same user name in the Fedora commit

Thanks for pinging me on this effort, as I did indeed write the unison.desktop file for the Fedora unison package [1]. However, I believe I had adapted it from a previous Fedora package spec file from the obsolete unison240 package [2].

For me any license that's acceptable to upstream is fine, i've added the MIT-0 license based on https://docs.fedoraproject.org/en-US/legal/misc/#_license_of_fedora_spec_files ... @mkrupcale please tell us if you have anything more specific in mind!

Given all of this, yes, MIT-0, is probably the appropriate license for the unison.desktop file.

The comment says Multi-master File synchronization tool. That's not a phrase that i find in unison's documentation. I would lean to "GUI for Unison file synchronizer".

The wording Multi-master File synchronization tool appears to have originated in an old unison v2.13 Fedora compatibility package [3,4]. I'm fine with adjusting the wording, however.

(I am assuming that packaging systems would be happier to have an upstream-provided desktop file, and drop their local one, seeing that as progress, even if it is a bit different.)

Yes, I'd prefer upstream to ship the .desktop file. Depending on whether this upstream .desktop file is installed as part of the build and/or if changes are needed, I will then use either desktop-file-install or desktop-file-validate on the package side [5].

References

1. https://src.fedoraproject.org/rpms/unison
2. https://src.fedoraproject.org/rpms/unison240/blob/c71fe778a6d99fc8338000bf168a7ffbb59e3627/f/unison240.spec#_109
3. https://src.fedoraproject.org/rpms/unison213/blob/c7eb2f1c5b24cc7b24267b30f81713cecc047f28/f/unison213.spec#_28
4. https://bugzilla.redhat.com/show_bug.cgi?id=433915
5. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_desktop_file_install_usage

I have been operating under the assumption that we are discussing adding a desktop file that is 1) aligned with unison upstream (because everything in the repo is) and 2) generally useful for all systems that use desktop files (because portability is important). I have not previously recognized flatpak as a naming authority for how unison calls itself, and I'm not inclined to do so, especially when they used a name that I would have immediately objected to had I been asked.

I guess the questions are:

• are there reasons not to call it unison-gui.desktop, other than flatpak?
• which logo is appropriate? We have U.svg, just the U, and Unison.svg, the whole word.
• (not a q) U.svg as an icon name makes sense within the unison repo, but it's not a great name in a system icon directory
• should we rename U.svg to unison-initial.svg and Unison.svg to unison-word.svg?
• unison doesn't install icons. should it?

I'm going to ask about the big picture on unison-hackers@.

I started to look at the link (thanks @mkrupcale for the references), but I don't like flathub's terms, so I stopped.

I have been operating under the assumption that we are discussing adding a desktop file that is 1) aligned with unison upstream (because everything in the repo is) and 2) generally useful for all systems that use desktop files (because portability is important).

I would agree with this sentiment. I think the Flatpak build / creation process should adjust the name as required rather than having upstream use the Flatpak-required name since Flatpak is obviously not the only (or perhaps even primary) means of distribution.

* which logo is appropriate?  We have U.svg, just the U, and Unison.svg, the whole word.

I would say U.svg is more appropriate as the desktop icon due to its square aspect ratio (again consistent with Icon Theme Specification [1]).

* (not a q) U.svg as an icon name makes sense within the unison repo, but it's not a great name in a system icon directory

Agreed, hence why I rename it during install.

* should we rename U.svg to unison-initial.svg and Unison.svg to unison-word.svg?

I think the current naming in the source repo is mostly fine and makes sense, but the package distribution install process does have to adjust the naming to be compliant with the system icon specification. If we do agree that U.svg is the correct choice (as I believe) for the desktop icon and wish for the file name to be compliant with the Icon Theme Specification, we could rename U.svg as unison.svg in the source repo, but that may not be necessary.

* unison doesn't install icons.   should it?

I'm fine with either the manual install during package build or if unison wishes to do the icon install as part of make install (as long as it installs to the expected location), but I'll have to use either desktop-file-install or desktop-file-validate on the package side in any case [2].

1. https://specifications.freedesktop.org/icon-theme-spec/latest/
2. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_desktop_file_install_usage

Thanks. I did try to look at the icon theme spec but it was too much to absorb quickly. Square makes sense.

I take away:

• it would be nice to rename U.svg to unison.svg and Unison.svg to unison-word.svg in the repo, and add a README, but it's not a big deal.
• It would be nice to install icons, but packagers (I package stuff for pkgsrc, so I totally get this) are used to having packaging install icons, so there is no real reason to link icons and desktop.
• I'm not missing anything about the "flathub expects the world to orient to flathub" issue.

* it would be nice to rename U.svg to unison.svg and Unison.svg to unison-word.svg in the repo, and add a README, but it's not a big deal.

Yeah, that would work fine. BTW the icons/U.${size}x${size}x16m.png files should be named consistently with U.svg as well to avoid confusion. The SVG format is technically an optional format of the Icon Theme Spec, so we also have to install the png format icons.

On the question of naming unison.desktop / unison-gui.desktop: I don't have too much preference one way or another (although I'd be curious what intention there is on making some non-GUI/background unison desktop launcher necessitating unison-gui.desktop as well as unison.desktop in the future), and the Desktop Entry Specification [1] only requires that the name be a valid D-Bus well-known name (a sequence of dot-separated elements containing ASCII letters, digits, dash, and underscore). They do suggest (with the language should) that it use the reverse DNS convention, which seems similar to the Flatpak application ID format, but as you pointed out, many applications do not follow that convention.

[1] https://specifications.freedesktop.org/desktop-entry-spec/latest/file-naming.html

As for intent, I view unison as primarliy a CUi program and it can run as a daemon. So the GUI is a special case, and e.g. syncthing has a desktop entry to start it in the background as a daemon, and then another to run the gui. Hence I lean to make all unison-foo now, to avoid wanting to change.

Thanks for the png/etc hint. I did realize that but it's not safe to assume :-)

I get the point of reverse dns as a unique source, but unison simply doesn't have such a name, and isn't likely to get one.

As for intent, I view unison as primarliy a CUi program and it can run as a daemon. So the GUI is a special case, and e.g. syncthing has a desktop entry to start it in the background as a daemon, and then another to run the gui. Hence I lean to make all unison-foo now, to avoid wanting to change.

It might make more sense to launch a unison daemon using the system service manager (e.g. systemd or similar) rather than using the Desktop Entry Spec (i.e. .desktop files). Like I said, I'm somewhat indifferent as to whether the GUI .desktop file itself is called unison.desktop or unison-gui.desktop, but I'm not sure it makes much sense to have a unison-daemon.desktop or similar as opposed to e.g. a unison.service systemd service unit. I'm not sure why syncthing chose the former approach, but I think it'd be better design to just install a service unit that gets enabled by default (if the user wants) rather than having the user start the daemon from a desktop entry.

Those are all good points. I don't mean to figure out how this would work, and there will be a lot of issues. Only that "there will never be anything else" is unsupportable.

I reviewed this again before the release, and my assessment is that a number of issues raised in discussion are not resolved:

• filename uses github
• icon strategy is unclear (not installed? naming?)

Thus today this PR, as it stands, is not mergeable. I added feedback, not as the meaning in issues of request for information, but in the PR sense of waiting for changes.

i completely agree with your assessment, and in any case it's not urgent...

my memory of the comments here is that there would be some discussion on a mailing list (but no links to any results of the discussion), and there are some unresolved questions:

• the ID (and icon/.desktop name) should be "unison" or "unison-gui"? (since neither are acceptable to flathub i have no opinion which one to use)
• this PR seeks to only add a .desktop file, if you like then it could install the icon as well (since it's referenced by the .desktop file), but i'm not sure if this is what you and/or distro packagers want

I realize desktop is gui-ish but there is also the notion of running unison as a daemon without the gui. Looking at my system's collection of files, the vast majority are for programs that are only GUI. I see syncthing, which has

syncthing-start.desktop
syncthing-ui.desktop

but of course there are text UIs so I think I land on unison-gui.

I see your point about Icons being separable, but I don't see how we can install a desktop file that points to an icon that isn't installed. We have a bunch of icons in the sources, and it's a little messy. I would prefer that some grasp/add-README/rationalize that and figure out which icons perhaps should be installed to align with how the broader Free Software world does things. I think that's putting a few different resolution in share/icons/hicolor.

I lean to using our existing icons if that's at all reasonable, and maybe deprecating the one that is natively in Adobe Illustrator because we shouldn't use non-Free tools. I think the svg ones were created because of that reason.
But it's a mess, and it would be great if someone cleaned things up. This really needs to be raised on hackers, as project doctrine is that the project is centered on mailing lists, not github. I'll send a note.

See #1163

Merging this PR closes #162